A typical memory error is related to the pooled memory that was not freed properly at the end of the application lifetime. For example, the following figure shows a case where a developer did not free the application data at kzApplicationUninitialize.
Here the error message shows the amount of memory and the description given to the data on allocation. Because the memory manager uses allocation tracking functionality, the error shows a reference number (order) for the specific allocation. If you have access to the source release of Kanzi, you can set a debug break flag in the kzc_memory_pool.cto break on the specific allocation, which is a good start for debugging in less obvious cases. In the above example, the application breaks in kzApplicationInitialize at the line where memory for the application data container is allocated.
#define KZC_MEMORY_POOL_DEBUG_INTERNAL 7062
To find out which memory manager is responsible for allocating and deallocating memory for a specific pointer, use kzcMemoryGetManager. You can call kzcMemoryGetManager for any pointer allocated with the Kanzi memory manager. After this, you can, for example, get information on used and available memory pools, or even print debug information on a specific pool using kzcMemoryPoolDump.
For ensured code stability check all potentially invalid input pointer parameters for your functions with kzcIsValidPointer. For example, to check the validity of the applicationData pointer, use:
kzsAssert(kzcIsValidPointer(applicationData));
Running Kanzi applications in multithread environments
Memory management best practices